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fidelity  issues  in  low  cost  aviation  and  networking.  This  paper 
addresses  the  issue  of  determining  a  simulator's  position  or 
utility  in  the  domain  of  networked  simulation.  In  order  to 
determine  the  simulator's  utility  in  this  domain,  assessment  and 
interfacing  methods  must  be  developed.  1ST  is  developing  a  new 
simulator  performance  assessment  system  and  a  general  purpose 
design  to  network  dissimilar  simulators. 


A  three  step  approach  of  design,  fabrication,  and  testing  is 
being  used  to  develop  a  simulator  performance  assessment  system. 
The  design  phase  includes  requirements  definitions,  and  design 
approaches.  The  fabrication  phase  includes  integration  of  off- 
the-shelf  equipment.  The  testing  phase  includes  both  system 
tests  which  validate  the  component  design,  and  operational  tests 
which  gather  and  reduce  simulator  performance  data.  IST's 
approach  to  assessing  simulator  performance  is  novel  in  two  ways: 
the  approach  uses  parameter  identification  methods  to  establish  a 
relationship  between  the  aircraft,  the  simulation,  and  the 
piloted  simulator;  and  it  uses  video  tape  to  capture  flight¬ 
relevant  cues  for  parameter  identification. 


To  network  dissimilar  simulators,  1ST  has  developed  a  prototype 
protocol  translation  system  based  on  SIMNET  technology.  We  have 
had  limited  success  using  the  Generic  Protocol  Translator  (GPT) 
to  interface  dissimilar  simulators. 


BACKGROUND 

The  Institute  for  Simulation  and  Training  (1ST)  at  the  University 
of  Central  Florida  is  presently  under  contract  to  DARPA  and  the 
Army's  Project  Manager  for  Training  Devices  (PM  TRADE)  to  develop 
a  low  cost  Aviation  Test  Bed  to  investigate  fidelity  issues  in 
low  cost  aviation  and  networking.  The  networking  research 
involves  developing  methods  to  connect  dissimilar  simulators, 
developing  bridging  techniques  to  connect  dissimilar  networks, 
and  developing  network  assessment  tools.  1ST  is  also  performing 
research  into  qualitative  (i.e.,  man  in  the  loop)  and 
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quantitative  (unmanned)  performance  characteristics  of  so-called 
"Selective  Fidelity"  flight  simulators. 

This  research  showed  several  interesting  facts  about  Selective 
Fidelity  flight  training  devices.  First,  flight  testing  of  such 
devices  to  determine  performance  and  handling  qualities  was  not 
available  in  any  consistent  format.  Secondly,  procurement 
agencies  did  not  appear  to  know  what  handling  and  performance 
qualities  to  specify  in  such  devices.  Thirdly,  each  device 
employed  simulations  of  different  aircraft  systems  to  teach  the 
same  basic  tasks.  Finally,  ancillary  devices  were  often  made 
available  to  augment  the  simulation. 


INTRODUCTION 

Traditionally,  low  cost  approaches  to  flight  simulation  have 
entailed  either  comprehensive  simulation  of  a  limited  number  of 
aircraft  functions,  or  a  limited  simulation  of  a  large  number  of 
aircraft  functions.  As  microprocessor  technology  has  advanced, 
low  cost  approaches  to  simulation  have  been  able  to  provide 
higher  fidelity  representations  of  the  simulated  environment. 
However,  two  phenomena  have  been  observed.  First,  fidelity 
increases  have  not  been  made  in  a  consistent  manner.  This  has 
resulted  in  simulation  devices  which  are  a  mix  of  high  cost  and 
low  cost  components  which  employ  the  notion  of  "Selective 
Fidelity."  Selective  fidelity  provides  different  levels  of 
realism  in  the  various  subsystems  of  a  simulation.  Selective 
fidelity  is  analogous  to  part  task  simulations.  Unfortunately, 
this  emphasis  on  low  cost  has  resulted  in  high  priority 
requirements  being  compromised  for  cost  conservation. 
Consequently,  cost  effective  simulations  are  being  developed 
which  do  not  meet  user  expectations  and  needs. 

The  second  phenomena  that  has  occurred  is  that  the  formal 
estimation  of  a  particular  selective  fidelity  device's  utility 
occurs  after  the  hardware  and  software  have  been  developed. 
Traditionally,  estimation  of  the  simulation's  utility  occurs 
prior  to  development.  Validation  of  its  utility  then  occurs 
during  development  and  operational  tests  of  the  simulator. 
Validation  tests  and  evaluation  must  occur  frequently  to  optimize 
the  utility  of  the  simulator  design. 

It  is  necessary  that  capabilities  of  simulators  and  training 
devices  be  quantified  and  validated  as  early  as  possible  in  order 
to  maximize  their  utility.  This  process  currently  occurs  in 
engineering  simulations  of  many  physical  systems.  Manned 
simulator  validation,  however,  is  different  than  physical  model 
validation  and  is  a  reason  why  validation  is  not  done  early.  In 
manned  simulator  validation,  one  may  obtain  perfect  correlation 
between  selected  vehicle  characteristics  and  the  simulation  model 
over  restricted  operating  ranges.  Correlation  is  achieved  by 
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matching  performance  curves  between  the  physical  model  and  the 
simulation.  However,  simplifications  in  the  mathematical  models, 
linearizing  non-linear  data,  and  quantization  effects  of  digital 
computing  cause  inconsistencies  to  occur.  These  inconsistencies 
limit  simulation  fidelity  to  known  levels.  These  limitations  in 
fidelity  can  limit  the  validity  of  the  simulation  when  a  human 
operator  is  a  part  of  the  simulator.  Since  all  of  the  cues  in 
the  actual  aircraft  cannot  be  represented  in  the  simulator,  some 
simulator  cues  must  be  exaggerated  to  get  the  simulator  to  "feel 
like  the  aircraft".  The  process  of  adjusting  simulator  cues  to 
pilot  perceptions  is  performed  on  a  trial  and  error  basis  and 
often  times  invalidates  the  physical  model. 


OBJECTIVES 

In  order  to  solve  the  problem  of  validating  simulator  fidelity, 
1ST  is  classifying  the  particular  domains  of  networked 
simulations.  Three  activities  are  necessary  to  meet  this 
objective.  First,  the  domain  of  networking  requirements  for 
flight  simulation  must  be  defined.  Second,  the  extent  of  a 
specific  networked  simulation's  position  in  the  domain  must  be 
determined  (i.e.,  validation  of  utility).  Third,  specific 
technologies  and  evaluation  methods  to  fill  voids  in  utility  must 
be  developed.  This  paper  addresses  the  second  objective,  the 
development  of  a  method  to  assess  validation  of  simulator 
utility. 

With  regard  to  fidelity,  this  paper  distinguishes  between 
simulator  performance  and  simulator  utility.  Simulator 
performance  is  the  degree  to  which  a  simulator  matches  the 
characteristics  of  the  design  basis  vehicle,  and  simulator 
utility  is  the  degree  to  which  the  simulation  is  able  to  meet  its 
intended  use.  The  distinction  is  critical  to  real  time,  pilot  in 
the  loop,  flight  simulators  because  it  allows  one  to  separately 
analyze  the  technical  and  behavioral  domains  of  the  simulation. 

In  order  to  determine  the  position  or  utility  of  a  simulator  in 
the  domain  of  networked  simulation,  assessment  and  interfacing 
methods  must  be  developed.  1ST  is  developing  a  simulator 
performance  assessment  system  and  a  general  purpose  design  to 
network  dissimilar  simulators. 


SIMULATOR  PERFORMANCE  ASSESSMENT  SYSTEM 

A  three  step  approach  of  design,  fabrication,  and  testing  is 
being  used  to  develop  a  simulator  performance  assessment  system. 
The  design  phase  includes  requirements  definition  in  addition  to 
the  development  and  specification  of  design  approaches.  The 
fabrication  phase  includes  integration  of  off-the-shelf 
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equipment.  The  testing  phase  includes  both  system  tests  which 
validate  the  component  design,  and  operational  tests  which  gather 
and  reduce  simulator  performance  data.  1ST  expects  this  three 
step  process  to  be  iterative  as  our  approach  matures. 


Design 

1ST  is  developing  a  design  to  capture  flight  simulator 
performance  and  handling  quality  characteristics  using  parameter 
identification  techniques.  These  characteristics  can  be  compared 
to  the  design  basis  aircraft  to  determine  simulator  performance. 
Flight  testing  of  aircraft  for  performance  and  handling  qualities 
involves  the  detection  of  control  inputs  and  capture  of  output 
information  which  contains  physical  variables.  Data  capture 
systems  normally  use  gyroscopes  and  accelerometers  to  collect 
analog  information.  Flight  test  data  is  typically  subject  to 
considerable  post  processing  to  obtain  useful  data  for  several 
reasons.  One  is  that  data  is  usually  collected  in  noisy 
environments,  and  noise  corrupts  data  (noise  can  be  due  to 
vibration,  turbulence,  and  RF  interference).  Another  reason  is 
that  control  conditions  are  also  difficult  to  duplicate 
consistently.  In  order  to  assess  simulator  fidelity  ,  1ST 
developed  a  method  to  collect  flight  relevant  parameters.  Data 
reduction  is  performed  as  a  post  processing  activity  using 
parameter  identification  methods.  Long  range  efforts  will  look 
at  filling  cue  voids  through  hardware  development  (e.g.,  low  cost 
control  loading  systems)  and  through  math  model  enhancement  (e.g. 
control  law  changes ) . 

Selective  fidelity  simulators  currently  under  development  rely 
heavily  on  visual  feedback  to  determine  flight  conditions  and 
attitudes.  Tactile  and  audio  feedback  are  secondary  cuing 
systems  in  such  devices.  Figure  l  shows  this  cuing  relationship 
between  the  aircraft  and  the  flight  simulator.  It  is  necessary 
to  capture  data  which  can  be  analyzed  to  determine  the  fidelity 
of  the  simulator  when  compared  to  the  aircraft  from  a  pilot  in 
the  loop  perspective.  Because  of  the  temporal  nature  of  the 
data,  it  is  necessary  to  have  a  measure  of  time  directly  coupled 
with  the  data. 

Cue  replacement  and  modification  is  critical  to  the  concept  of 
"Selective  Fidelity."  However,  cue  replacement/modification 
concepts  have  not  been  applied  consistently  in  flight  simulation. 
As  an  analogy  to  help  understand  the  cue  replacement  process, 
studies  have  been  conducted  in  the  past  with  respect  to 
handicapped  individuals  and  the  augmentation  of  cues  through 
hardware  and  software  (Nickerson,  1978;  Elliott,  1978).  A  simple 
example  of  cue  replacement  could  be  the  use  of  hearing  aids  for 
the  hearing  impaired,  or  audible  devices  for  proximity  detection 
by  the  blind.  The  hearing  aid  augments  or  enhances  a  missing 
human  sense.  In  a  similar  manner,  our  study  investigates 
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DATA  ANALYSIS/ACQUISITION  SYSTEM 

THEORETICAL  BASIS 

•  Aircraft  Cues  Are: 

•  Selective  Fidelity  Simulator 

•  Visual 

Cues  Are: 

*  Tactile 

-  Visual 

•  Audio 

•  Tactile  (limited) 

-  Vestibular 

•  Audio  (limited) 

♦  Aircraft  Plight  Tests  Use: 

•  Selective  Fidelity  Tests  Use: 

•  Video  Cameras  Oimited) 

•  Video  Cameras 

-  Force  Gauges 

•  Force  Gauges  (limited) 

-  Audio  Recording 

•  Audio  Recording 

•  Accelerometers/Gyros 

•  Analog/Digital  Data 

Figure  1 


situations  where  a  fully  capable  individual  accustomed  to 
experiencing  a  full  range  of  flight  cues  is  exposed  to  a 
simulator  with  degraded  or  missing  cues.  The  problem  is 
identifying  those  cues  which  are  necessary  for  the  operator  to 
perform  a  specific  function  within  the  context  of  a  larger  goal. 


In  order  to  determine  specific  cue  replacement  parameters,  it  is 
necessary  to  determine  the  degree  of  fidelity  (performance) 
offered  by  the  specific  simulation  and  the  context  within  which 
the  simulation  is  delivered  (utility).  The  degree  of  fidelity 
must  be  compared  to  some  quantified  baseline  to  allow  for 
comparisons  of  simulation  approaches.  IST's  approach  uses  actual 
aircraft  data  as  a  base  of  comparison.  In  our  approach, 
simulator  flight  testing  is  first  conducted  to  compare  simulator 
to  aircraft  performance.  Next,  a  human  is  inserted  in  the 
simulation  loop  to  study  the  effect  of  how  the  human  perceives 
the  performance  of  the  simulator  compared  to  the  actual  aircraft. 
Studies  are  conducted  on  isolated  tasks  (e.g.,  rolls  at  l-G)  as 
well  as  embedded  tasks  (e.g.  rolls  as  a  part  of  a  tactical 
maneuver ) .  Cooper-Harper  ratings  are  used  to  relate  simulation 
performance  to  simulation  utility.  Cooper-Harper  variation  with 
task  complexity  is  also  studied.  This  building  block  approach  is 
firmly  rooted  in  the  performance  of  the  actual  vehicle,  making 
analysis  a  straightforward  matter.  The  simulator  can  also  be  a 
control  device  to  suppress  selective  cues. 
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The  current  method  used  for  determining  simulator  performance  is 
to  compare  the  simulator's  aerodynamic  and  performance  curves  to 
a  given  design  basis  aircraft  over  a  limited  operating  range. 
However,  the  relationship  of  simulator  performance  to  simulator 
utility  is  not  clear.  This  lack  of  clarity  results  in 
unpredictable  utility  when  simulator  performance  is  changed.  A 
new  approach,  description  following,  is  novel  from  two  points  of 
view.  First,  the  approach  uses  parameter  identification  methods 
to  establish  a  relationship  between  the  aircraft,  the  simulation, 
and  the  piloted  simulator.  Secondly,  the  approach  uses  video 
tape  to  capture  flight-relevant  cues  for  parameter 
identification. 

Parameter  identification  is  currently  used  to  glean  parameters 
from  aircraft  flight  tests  that  can  be  used  for  a  simulation. 

1ST  is  studying  the  feasibility  of  using  similar  parameter 
identification  methods  to  glean  simulator  parameters  which  could 
then  be  compared  to  the  actual  aircraft.  This  would  allow 
simulation  validation  without  detailed  knowledge  of  the  specific 
implementing  software  and  hardware.  The  parameter  identification 
method  will  include  unmanned  and  manned  flight.  This  approach 
accounts  for  the  pilot  in  the  loop  and  quantifies  the  effect  of 
specific  cues  that  contribute  to  the  acceptability  of  a 
simulation.  Parameter  identification  methods  will  not  only  be  a 
valid  method  to  compare  simulator  performance  to  the  actual 
aircraft,  but  will  also  be  valid  in  IST/UCF's  cue  replacement 
analysis. 

Since  the  most  significant  cues  in  selective  fidelity  flight 
simulators  are  visual  in  nature,  1ST  believes  that  video  tape  is 
a  valid  method  of  capturing  pertinent  simulator  performance  and 
utility  data.  Tactile  and  audio  cues  also  represent  a 
potentially  significant  source  of  cues  to  pilots,  so  these  cues 
will  also  be  captured  and  correlated  with  visual  information. 

A  suite  of  test  equipment  is  being  developed  to  capture  flight 
simulator  performance  and  handling  qualities  data.  Ideally,  such 
equipment  should  gather  data  without  intruding  into  the  simulator 
or  affecting  its  operation.  In  addition,  sampling  rates  should 
be  such  that  critical  data  is  not  lost  and  time  skewing  is 
minimized.  Figure  2  shows  a  diagram  of  IST/UCF's  hardware  design 
for  flight  simulator  data  collection.  This  system  is  similar  in 
configuration  to  one  used  at  the  Naval  Air  Test  Center  (NATC)  for 
human  factors  evaluations  during  flight  test. 

When  a  data  sampling  system  is  designed,  one  must  determine  if 
the  system  being  sampled  is  discrete  or  continuous.  In  the  case 
of  data  acquisition,  feedback  into  the  simulator  is  not 
important.  This  fact  simplifies  any  mathematical  analysis  if  the 
data  acquisition  is  unobtrusive  (i.e.,  does  not  influence  the 
operation  of  the  simulator).  In  the  case  of  a  simulator,  the 
point  where  the  sample  is  taken  is  critical  to  the  determination 
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Figure  2 


of  continuous  or  discrete  sampled  systems.  We  have  concluded 
that  capturing  information  in  an  analog  format  is  most 
appropriate  because,  for  the  most  part,  the  data  can  be  obtained 
from  standard  output  devices. 

Video  tape  is  the  initial  format  for  most  of  the  data  to  be 
captured.  This  approach  avoids  intrusion  into  the  simulator  and 
the  problems  associated  with  discrete  sampling  influences  back  to 
the  baseline  system.  Problems  associated  with  proprietary 
hardware  and  software  are  also  avoided,  along  with  the  attendant 
test  suite  reconfiguration  necessary  for  implementations  which 
may  be  in  hardware  on  one  simulator  and  in  software  on  another 
device . 

Sampling  rates  are  critical  in  flight  test  methods.  IST/UCF  has 
analyzed  the  requirements  of  simulators  to  ascertain  the 
suitability  of  using  video  as  a  medium  to  record  simulator  flight 
tests.  Nyquist's  sampling  theory  dictates  that  the  sampling 
frequency  should  be  at  a  rate  at  least  twice  the  natural 
frequency  of  system  under  study  (Haykin,  1978).  Typical  values 
of  the  natural  frequency  for  jet  aircraft  is  3Hz.  (Roskam, 

1972. ) 

The  pacing  factor  in  the  IST/UCF  system  is  both  the  video  camera 
configuration  and  the  use  of  a  single  video  tape  or  master  clock 
to  synchronize  multiple  tapes.  The  video  tape  is  limited  to  60 
Hz  field  rates  for  compatibility  with  commercially  available  NTSC 
television  standards.  Therefore,  sampling  rates  cannot  exceed  60 
Hz  in  the  IST/UCF  design.  The  number  of  cameras  becomes  the 
divisor  in  determining  the  sampling  rate  for  data  collection. 
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The  simple  equation  below  shows  this  relationship. 


Sampling  freq  (ws)  =  video  tape  players  x  video  tape  rate  <’60  Hz'! 

number  of  cameras 

IST/UCF  is  using  analog  to  digital  converters  and  digital  to 
digital  converters  to  capture  control  information  not  amenable  to 
video.  In  the  F-16  simulator  this  information  consists  of 
control  stick  inputs  (as  the  control  stick  is  stationary  and  is 
responsive  to  pilot  force  inputs).  In  addition,  several  discrete 
controls  on  the  HOTAS  (Hands  On  Throttle  And  Stick)  are  necessary 
for  both  human  factors  and  flight  performance  tests. 

Collecting  information  from  flight  instruments  is  being  conducted 
in  a  manner  similar  to  that  which  humans  use  to  receive  the 
information.  As  stated  earlier,  the  primary  source  of  stimulus 
for  the  trainee  in  selective  fidelity  devices  is  visual.  We 
believe  that  visual  stimulus  is  being  used  to  replace  many 
vestibular  cues  common  in  most  aircraft.  For  example,  the  cues 
experienced  by  the  pilot  during  a  simple  roll  are  vestibular, 
tactile  and  visual.  Most  selective  fidelity  devices  do  not 
contain  control  loading  systems  which  provide  necessary  tactile 
feedback  or  motion  systems  which  provide  vestibular  cues. 
Therefore,  the  visual  system  of  the  human  has  the  task  of 
providing  the  stimulus  to  give  the  sensation  of  conducting,  for 
example,  a  coordinated  turn.  This  information  is  currently  being 
collected  and  will  be  analyzed  for  both  the  fixed  wing  and  rotary 
wing  situation.  IST/UCF  believes  that  a  low  cost  control  loading 
system  for  tactile  feedback  coupled  with  a  quality  sound  system 
for  audio  and  limited  vestibular  cues  will  be  necessary  to 
increase  the  utility  of  many  selective  fidelity  simulators. 

Using  the  flight  simulator  as  the  test  vehicle  for  parameter 
identification  purposes  is  new.  The  use  of  parameter 
identification  methods  from  the  simulator  results  in  two  useful 
products.  First,  the  manifestation  of  specific  simulator 
performance  parameters  can  be  visualized  as  a  system  output. 

This  fact  is  useful  to  study  and  validate  design  parameters  such 
as  update  rate,  integration  routines,  natural  frequency  and  phase 
lag  of  the  simulator.  Second,  parameter  identification  can  be 
useful  to  study  potential  changes  in  simulator  control  laws, 
which  we  believe  can  have  a  large  effect  on  simulator  utility. 
Relationships  between  simulator  control  laws  (based  on  differing 
degrees  of  acceptability  using  such  methods  as  Cooper-  Harper 
ratings),  theoretical  aircraft  control  laws,  and  actual  aircraft 
control  laws  can  then  be  studied  to  determine  any  mathematical 
linkage.  Trends  in  different  flight  regimes  can  also  be  studied 
using  the  above  methodology. 

Parameter  identification  normally  attempts  matching  time 
histories  between  the  aircraft  and  simulator.  The  baseline  data 
(normally  aircraft  flight  test  data)  must  normally  be  processed 
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through  some  type  of  Kalman  filter  to  remove  random  noise. 
Aliasing  errors  must  also  be  removed.  The  case  under  study  is 
easier  because  we  are  using  processed  flight  test  data. 

Simulation  dynamic  tests  can  also  be  controlled  to  eliminate  or 
introduce  noise  and  can  be  performed  in  a  repeated  manner. 
However,  as  with  all  parameter  identification  studies,  the 
specific  parameter  matching  should  be  decided  upon  prior  to  the 
study.  IST/UCF  believes  that  matching  frequency  response 
characteristics  between  the  simulator  and  the  aircraft  is 
critical  to  pilot  acceptance.  In  addition,  performance 
characteristics,  such  as  rate  of  climb,  stall  speeds,  etc.  are 
important  to  pilot  acceptance.  Frequency  response 
characteristics  must  consider  the  closed  loop  aircraft  response 
at  the  flight  controls  and  visual  system. 

Three  methods  of  parameter  identification  are  currently  used;  the 
Equation  Error  method,  the  Output  Error  method,  and  the  Maximum 
Likelihood  method  (Duval,  1989).  The  Equation  Error  method  is 
the  easiest  of  the  three  to  implement,  but  requires  a  measurement 
of  all  vehicle  states  and  controls  and  gives  biased  parameter 
estimates  in  the  presence  of  system  noise.  The  Output  Error 
method  generates  system  states  by  integration  of  the  equations  of 
motion.  In  the  Output  Error  methods,  successive  iterations  are 
necessary  to  tune  the  time  histories.  The  Maximum  Likelihood 
method  is  the  most  general  with  respect  to  data  needs,  but 
requires  extensive  processing  through  some  type  of  Kalman  Filter. 
We  believe  that  the  Equation  Error  method  can  be  used  to  extract 
parameters  from  the  simulation  because  of  the  noise  free 
simulation  environment,  the  ability  to  control  the  initial 
vehicle  state,  and  the  ability  to  measure  all  controls  and 
vehicle  states. 


Fabrication 

The  system  under  development  at  1ST  will  consist  of  a  three 
camera  apparatus  with  the  potential  for  an  array  of  up  to  four 
camera  inputs,  each  of  which  will  be  on  line  with  its  own  video 
recorder.  This  is  preferable  over  several  multiplexing 
techniques  which  require  only  one  VCR  and  a  video  multiplexer. 
While  requiring  somewhat  less  hardware,  it  was  concluded  that  the 
synchronization  of  video  multiplexing  hardware  would  not  be 
sufficient  for  our  experimentation,  since  ultimate  success  lies 
in  the  frame-by-frame  evaluation  of  the  data. 

The  camera  equipment  consists  of  SONY  DXC-325  Color  Video  cameras 
and  SONY  VO-9800  U-matic  Videocassette  recorders  or  their 
equivalents.  The  apparatus  will  be  driven  by  means  of  an  ADX 
synchro  system  which  will  drive  the  video  recorders  and 
synchronize  on  a  frame-by-frame  basis. 

The  accuracy  of  this  video  setup  was  found  to  be  more  acceptable 
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than  multiplexing.  This  synchro  unit  will  also  provide  a  digital 
clock  which  will  emit  a  clock  pulse  at  the  same  rate  as  each 
frame  is  recorded.  From  this,  analog  and  digital  signals  from 
various  simulator  controls  can  be  sampled  by  means  of  PC  data 
acquisition  hardware,  specifically  the  MetraByte  DAS-20  data 
acquisition  board,  and  time  stamped  to  correlate  to  the  data 
retrieved  from  each  frame  of  video.  This  process,  which  is  to 
some  degree  intrusive,  will  be  done  on  1ST  hardware  for  1ST 
purposes,  but  will  not  necessarily  be  a  requirement  for  remote 
applications . 

Normal  configuration  on  selective  fidelity  devices  observed  by 
1ST  will  not  exceed  3  cameras.  One  camera  will  be  used  for  the 
Head  Up  Display  (HUD),  one  camera  for  instruments,  and  one  camera 
for  stick  and  throttle.  The  system  designed  by  IST/UCF  can 
accommodate  additional  channels  of  video  information  by  using  a 
set  of  mirrors  to  divide  data  being  received  by  a  camera. 

Dividing  video  information  on  one  camera  is  accompanied  by  a  loss 
in  resolution  proportif  nal  to  the  camera  aperture  consumed  by 
each  image. 

Capture  of  analog  information  is  controllable  at  nominal 
frequencies  of  up  to  4000  Hz  for  all  analog  signals.  This  is  far 
in  excess  of  the  individual  aircraft's  natural  frequency.  Up  to 
16  single  ended  values  may  be  sampled  with  conversion  to  digital 
consuming  12  micro  seconds. 

The  problems  associated  with  video  capture  revolve  around 
parameter  identification  methods.  Aircraft  parameter 
identification  methods  are  subject  to  noise  from  many  sources. 

As  such,  when  data  is  pulled  from  instruments,  indicators,  or 
HUDs,  performance  parameters  may  become  corrupted  in  ways 
different  from  the  actual  aircraft.  The  primary  corrupting 
factor  is  due  to  the  simulation  of  the  specific  instrument. 

State  variables  are  used  as  inputs  to  an  instrument  model.  The 
specific  instrument  model  then  simulates  the  characteristics  of 
the  instrument.  On  the  other  hand,  aircraft  effects  such  as 
aeroelastic  bending  and  vibration  can  corrupt  data.  Therefore, 
the  relationship  between  the  simulation  and  aircraft  from  an 
engineering  point  of  view  is  not  apparent.  Parameter 
identification  techniques  are  being  developed  at  IST/UCF  in  order 
to  study  these  relationships. 

Testing 

IST/UCF  has  performed  two  types  of  testing  on  its  simulation 
validation  system;  one  set  of  tests  on  the  concept  and  one  set  of 
tests  on  the  parameter  identification  methods.  Concept  tests 
used  the  concept  of  progressively  building  on  a  validated 
baseline.  The  baseline  in  the  case  of  IST/UCF's  work  has  been 
the  F-16A  aircraft. 
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IST/UCF  has  obtained  flight  test  data  from  the  F-16A  courtesy  of 
the  US  Air  Force  F-16  System  Program  Office.  IST/UCF  has  two 
F-16  simulators  known  as  the  Avionics  Situational  Awareness 
Trainers  (ASAT)  which  were  manufactured  by  Perceptronics .  These 
networkable  devices  were  designed  to  train  Beyond  Visual  Range 
(BVR)  target  acguisition  and  engagement.  These  devices  gene. ^te 
packets  of  data  on  a  local  area  network  which  allow  the  two 
devices  to  train  two  sets  of  F-16  aircrews.  IST/UCF  is 
developing  software  which  can  change  the  data  packets  to  allow 
the  output  of  any  variable  set  which  does  not  exceed  the  byte 
length  allocated  to  unmodified  ASAT-  Using  this  software  allows 
IST/UCr  zo  output  state  variables  or  other  pertinent  data  (e.g., 
stability  derivatives)  which  are  used  as  inputs  to  the  HUD.  In 
this  manner,  1ST  is  able  to  verify  ASAT  perfoi trance  on  a  basis 
similar  to  the  actual  F-16.  Effects  of  instrument  simulations, 
if  any,  can  be  isolated  by  comparing  instrument  indications  to 
state  variables.  Spatial  and  temporal  comparisons  are  made 
between  the  instrument  indication  and  the  simulation  state 
variable.  In  addition,  initial  vehicle  physical  parameters,  such 
as  weight  and  inertias  can  be  varied  to  a  limited  extent  to  match 
those  of  the  test  aircraft. 

IST/UCF  has  also  performed  limited  flight  tests  to  begin  the 
parameter  identification  process.  Initial  tests  have  been 
limited  to  roll  performance  tests.  These  tests  are  extremely 
useful  because  of  the  single  axis  nature  of  the  maneuver. 
Performance  tests  include  time  to  achieve  a  30  degree,  90  degree, 
180  degree,  and  360  degree  roll  attitude  at  a  stable  mach  number, 
altitude,  and  1-g  flight  condition.  Initial  tests  were  performed 
using  students  as  pilots.  IST/UCF  is  in  the  process  of  obtaining 
a  software  program  known  as  the  Controls  and  Simulation  Test  Loop 
Environment  (CASTLE)  from  the  Naval  Air  Test  Center.  CASTLE  can 
be  used  to  provide  repeatable  system  trim  and  forcing  functions 
using  an  off  line  trim  program. 

Initial  concept  testing  has  been  completed  by  IST/UCF.  Several 
maneuvers  were  executed  repeatedly  for  consistency  purposes. 

There  were  several  purposes  for  these  concept  tests.  The  first 
was  to  investigate  any  video  synchronization  problems  between  the 
HUD  and  the  video  camera.  The  second  was  to  investigate  physical 
restrictions  in  data  gathering  with  respect  to  camera  set-up, 
lighting,  ?nd  special  fixtures  necessary.  The  third  was  to 
ascertain  qualitatively  if  sufficient  resolution  and  contrast 
were  available  to  acquire  meaningful  data  from  a  video  camera. 
Video  synchronization  differences  are  apparent  in  the  tests  run 
at  IST/UCF.  A  band  is  often  visible  in  the  video  due  to 
differences  in  the  synchronization  in  the  vertical  retrace  of  the 
camera  and  source  imagery.  This  effect  is  quite  common  and  can 
be  alleviated  by  using  an  external  synchronizcition  signal  to 
control  the  image  source  and  image  collection  devices.  Close 
examination,  though,  reveals  an  apparent  loss  of  contrast  and  not 
resolution.  Thereiore,  if  a  high  contrast  ratio  image  source  is 
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used,  video  tape  is  acceptable  to  capture  pertinent  imagery  from 
a  synchronization,  but  not  aesthetic,  point  of  view. 

Physical  restrictions  to  gathering  data  were  investigated. 
Physical  restrictions  included  lighting,  support  fixtures,  and 
camera  configuration.  Lighting  has  proved  to  be  the  physical 
item  with  the  greatest  degree  of  sensitivity.  First,  some 
aircraft  instruments  are  sources  of  light  (i.e.,  self 
illuminating),  while  other  instruments  require  an  external 
lighting  source.  In  the  case  of  IST/UCF's  initial  experiments, 
the  HUD  was  a  source  of  lighting,  while  a  Liquid  Crystal  Diode 
(LCD)  stop  watch  required  external  lighting  to  be  visible  to  the 
camera.  External  lighting  causes  glare  on  a  CRT  face  depending 
on  the  orientation  and  type  of  lighting  source.  Therefore,  a 
focused  light  source  was  aimed  at  the  stop  watch  to  have 
sufficient  lighting  to  view  both  images  from  a  single  unmodified 
aperture.  Other  physical  constraints  are  caused  by  the  physical 
configuration  of  the  simulator.  A  standard  camera  tripod  and 
commercial  test  fixtures  can  accommodate  most  configurations  on 
selective  fidelity  devices.  Figure  3  depicts  this  test  set-up. 
Manned  experiments  may  require  additional  video  camera  lenses  to 
allow  simultaneous  data  acquisition  and  piloted  operation. 

Camera  weight  and  size  should  be  minimized  to  minimize  visual 
obstructions  due  to  the  camera  and  support  apparatus.  Remote 
video  taping  is  therefore  desired  and  is  being  implemented  by 
IST/UCF.  Test  results  for  simulated  roll  experiments  are 
depicted  in  Figure  4 . 


Figure  3 
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Additional  testing  will  be  performed  in  the  future  using  a  pilot 
in  the  loop,  operational  simulation  validation  hardware,  and 
expanded  flight  tests  to  facilitate  parameter  identification 
studies.  Tests  will  include  both  fixed  and  rotary  wing  aircraft 
and  simulators. 


NETWORKING 

The  simulators  which  we  have  been  referring  to  are  networked 
devices.  It  is  necessary  to  develop  techniques  which  allow  a 
flexible  arrangement  of  simulator  assets  so  that  experimentation 
can  be  performed.  Until  recently,  the  SIMNET  units  could  not  be 
networked  with  other  simulators  in  our  laboratories.  IST/UCF  has 
developed  a  prototype  protocol  translation  system  based  on  SIMNET 
technology,  which  is  also  being  extended  to  other  applications 
outside  of  SIMNET.  This  device  can  be  used  to  allow  a  non-SIMNET 
training  device  to  connect  and  interact  with  the  SIMNET  trainers. 

Currently,  networking  techniques  are  being  developed  which  will 
allow  a  variety  of  devices  to  interact  in  real  time.  A  Generic 
Protocol  Translator  (GPT)  is  the  key  element  of  interfacing  an 
individual  device  into  a  larger  system  of  networked  simulators 
because  it  allows  two  dissimilar  devices  to  communicate  with  one 
another  as  if  they  were  operating  in  the  same  environment. 

Without  the  Generic  Protocol  Translation  device,  the  packets  of 
one  simulator  would  be  ignored  by  any  destination  simulator  which 
did  not  operate  under  the  same  protocol  as  the  transmitting 
simulator.  The  translation  task,  which  is  to  be  performed  by  the 
GPT,  is  divided  into  two  functions:  (1)  the  user  interface  and 
(2)  the  protocol  translator. 

The  user  interface  allows  for  an  individual  to  access  the  GPT  and 
describe  the  rules  and  formats  of  his  simulator's  protocol.  The 
Generic  Protocol  Translator  must  be  given  certain  control 
parameters  and  characteristics  of  the  protocols  between  which  it 
will  be  translating.  These  parameters  and  characteristics  will 
be  stored  in  the  GPT's  memory  where  the  user  may  access  this  file 
later  and  edit  as  needed.  Once  the  information  is  compiled  for 
two  systems,  the  GPT  will  compare  the  two  formats  and  create 
algorithms  for  translating  discrepancies  which  may  exist  between 
the  protocols  of  the  two  systems. 

Other  information  that  must  be  provided  to  the  GPT  is  any  timing 
considerations  that  are  necessary  for  proper  interfacing  of  two 
unlike  devices.  Timing  information  is  provided  by  the  user  to 
the  GPT  during  the  User  Interface  session.  The  user  must  define 
whether  his  device  operates  in  a  synchronous  or  an  asynchronous 
mode.  If  the  device  is  a  synchronous  simulator,  it  will  receive 
and  transmit  packets  at  a  rate  which  is  dependant  on  the 
simulator's  design.  When  this  simulator  is  interfaced  with  an 
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asynchronous  device,  there  is  a  chance  that  this  device  will  not 
be  able  to  provide  enough  packets  to  interface  properly.  In  this 
case,  the  GPT  will  perforin  an  extrapolation  of  the  asynchronous 
simulator's  characteristics  and  supply  the  synchronous  simulator 
with  the  necessary  packets.  In  the  case  of  interfacing  two 
synchronous  simulators  with  different  data  rates,  the  GPT  must 
supply  the  simulator  with  the  greater  data  rate  with  necessary 
packet  information. 

The  protocol  translation  portion  of  the  GPT  device  will  use  the 
algorithms  developed  during  the  User  Interface  session  to  receive 
the  packet  from  a  source  simulator  and  translate  it  into  a  format 
understandable  by  a  destination  simulator.  At  IST's  Networking 
and  Communications  Technology  Laboratory  we  have  had  limited 
success  in  using  a  protocol  translator  to  interface  dissimilar 
simulators  .  The  interconnection  of  dissimilar  simulators  into  a 
single  environment  was  performed  by  1ST  as  a  proof-of-principle 
experiment  to  demonstrate  the  ability  to  network  two  simulators 
that  operate  under  different  communications  protocols. 


ASAT  TO  SIMNET  PROTOCOL  TRANSLATOR 

Two  platforms  were  used  for  this  experiment.  The  first  was  the 
Avionics  Situational  Awareness  Trainer  (ASAT)  from  Perceptronics , 
Inc.  The  second  platform  was  a  SIMNET  Ml  tank  simulator.  To 
achieve  networked  communications  between  the  two  simulators,  a 
protocol  translator  was  placed  as  a  node  on  the  ETHERNET  network 
(Figure  5  depicts  the  ASAT/SIMNET  Network).  The  translator 
listens  to  the  network  traffic  and  copies  any  packets  which  are 
transmitted  by  the  ASAT  trainer.  Every  packet  copied  by  the 
protocol  translator  is  converted  to  the  proper  SIMNET  format  and 
transmitted  onto  the  ETHERNET  so  that  the  SIMNET  units  can 
portray  on  their  visuals  a  proper  model  of  the  ASAT.  The 
conversion  is  accomplished  within  30  ms.  A  complete  description 
of  the  protocol  translator's  hardware  and  software  is  available 
in  Cadiz  (1990) . 

The  protocol  translator  was  developed  on  a  20  Mhz  80386  AT 
compatible  PC.  To  connect  it  to  the  ETHERNET  network,  the 
translating  PC  was  outfitted  with  a  3Com  Etherlink  II  Network 
Adapter.  The  3Com  board  was  configured  to  operate  in  promiscuous 
mode  so  that  it  would  monitor  all  packets  transmitted  onto  the 
network.  The  translator  would  filter  all  unwanted  packets, 
taking  only  the  properly  addressed  packets  into  its  memory  for 
processing. 
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ASAT  Protocol 

Due  to  the  ASAT's  limited  application,  the  ASAT  Protocol  is  much 
simpler  than  the  SIMNET  protocol.  Currently  there  are  four 
different  types  of  packets  that  the  ASATs  use  to  initialize  and 
execute  an  exercise; 

•  Packet  Type  0;  used  during  initialization  of  an  exercise  to 
perform  handshaking,  determine  the  master  system,  and 
calculate  the  number  of  enemy  targets  and  friendly  vehicles 

•  Packet  Type  1:  activates  the  vehicles  with  their  proper 
parameters  (e.g.,  position,  orientation,  speed,  weapons' 
capabilities) 

•  Packet  Type  8:  transmits  a  vehicle's  location,  orientation, 
status,  etc.  It  also  provides  this  information  for  any 
missiles  that  the  vehicle  may  fire.  Packet  Type  8  has 
functions  similar  to  SIMNET 's  Vehicle  Appearance  PDU. 

•  Packet  Type  9:  the  vehicle  appearance  packet  for  all 
computerized  targets. 

By  using  these  four  packets,  the  ASAT  simulation  environment  can 
support  up  to  twelve  vehicles  (including  computerized  targets)  in 
a  single  exercise. 


SIMNET  Protocol 

The  communications  protocol  used  by  the  SIMNET  network  is  the 
SIMNET  Protocol  Version  6.0  which  is  described  in  Pope  (1989). 

The  SIMNET  protocol  has  three  subprotocols:  Data  Collection 
Protocol,  Association  Protocol,  and  the  Simulation  Protocol.  The 
only  protocol  of  interest  in  the  translator  experiment  was  the 
Simulation  Protocol.  The  Simulation  Protocol  provides  the 
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necessary  tools  for  allowing  a  simulator  to  describe  any  of  its 
actions  that  may  affect  other  nodes  participating  in  the  same 
exercise.  Several  of  the  functions  that  are  furnished  by  the 
simulation  protocol  are: 

•  Activation  and  Deactivation 

•  Vehicle  Appearance  Updates 

•  Vehicle  Status 

•  Weapons'  Effects  and  Interactions 

•  Detection  and  Reactions  to  Vehicle  Collisions 

•  Service  and  Repairs  to  Vehicles 


ASAT/SIMNET  Interfacing  Problems 

In  trying  to  network  the  ASAT  and  SIMNET  simulators,  several 
complications  prevented  their  complete  interfacing.  One  was  that 
the  SIMNET  vehicles  could  not  be  initialized  properly  into  the 
ASAT  Environment.  Proper  activation  of  the  SIMNET  simulators 
would  allow  them  to  be  "legal”  players  in  the  ASAT  exercise.  In 
the  SIMNET  environment,  it  is  not  critical  for  this  function  to 
be  performed.  If  a  vehicle  is  not  activated  properly,  the  other 
vehicles  on  the  network  will  proceed  to  acknowledge  the  vehicle's 
existence  in  the  exercise  and  allow  it  to  interact  with  other 
players.  However,  the  ASATs  will  not  allow  another  vehicle  to 
enter  their  exercise  without  proper  initialization. 

Upon  activation,  the  ASAT  trainers  undergo  a  handshaking  process. 
From  this  process  each  ASAT  creates  a  list  of  all  participants  in 
the  exercise.  If  a  vehicle  is  not  involved  in  this 
initialization  procedure,  it  will  not  be  a  participant,  and  the 
rest  of  the  simulators  will  ignore  any  packets  received  with  the 
source  address  of  that  vehicle.  The  SIMNET 's  inabilities  to 
perform  the  handshaking  and  to  be  placed  on  the  players  list  made 
it  impossible  for  the  SIMNETs  to  be  initialized  into  the  ASAT 
exercise. 

Other  complications  arose  because  the  ASATs  were  designed  to 
train  pilots  in  air-to-air  Beyond  Visual  Range  targeting 
techniques,  as  opposed  to  SIMNET's  ground  level  and  low  altitude 
training  applications.  One  problem  was  that  the  ASATs  do  not 
support  vehicles  which  have  zero  velocity.  Because  the  SIMNET 
Mis  are  ground  vehicles,  they  operate  at  low  velocities  and  are 
static  in  many  situations  (zero  velocity).  These  scenarios  could 
not  be  duplicated  in  the  ASAT  environment  without  modifying  the 
ASAT  source  code.  The  design  requirements  of  the  ASATs  did  not 
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call  for  the  existence  of  ground  vehicles,  therefore  no  dynamic 
models  for  vehicles  such  as  tanks  are  provided  in  the  ASAT 
environment.  The  models  that  are  provided  by  the  ASAT  trainers 
are  the  F-16,  Mig21,  Mig29,  and  a  generic  missile. 

Another  problem  was  the  ASAT  addressing  scheme:  its  protocol  is 
not  of  a  standard  IEEE  802.3  format.  The  ASATs  begin  their 
packet  with  the  source  address  immediately  followed  by  data.  In 
ETHERNET,  the  packet  begins  with  the  Source  Address,  Destination 
Address,  and  type  field,  followed  by  the  packet  data  (see  Figure 
6) . 
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After  considering  these  problems,  we  focused  the  experiment  on 
translating  ASAT  vehicle  appearance  updates  to  SIMNET  Vehicle 
Appearance  Protocol  Data  Units  (VA  PDUs).  By  translating  the 
ASAT  vehicle  appearance  updates  into  SIMNET  VA  PDUs,  we  could 
furnish  all  entities  of  the  SIMNET  simulation  exercise  with 
information  related  to  the  location,  velocity,  orientation,  and 
appearance  of  the  ASAT  F-16. 

SIMNET  Vehicle  Appearance  PDU  Template 

The  ASAT  to  SIMNET  Protocol  Translator  creates  a  template  of  the 
SIMNET  VA  PDU  for  each  ASAT  packet  that  is  to  be  translated.  The 
packet  structure  for  the  SIMNET  VA  PDU  template  is  shown  in 
Figure  7a.  This  template  is  supplemented  by  translated  ASAT  data 
to  create  a  complete  VA  PDU  for  the  ASAT.  The  fields  which  are 
supplied  by  the  ASAT  packet  are: 

•  Source  Address 

•  Vehicle  Location 

•  Vehicle  Speed 

•  Rotation  (derived  from  ASAT  roll,  pitch,  and  yaw  angles) 

The  PDU  created  by  incorporating  this  information  with  the  SIMNET 
VA  PDU  template  provides  any  SIMNET  node  with  sufficient 
information  to  depict  the  ASAT  vehicle  in  the  SIMNET  simulation. 
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ASAT  Packet  Type  8  (appearance  packet) 

The  ASAT  Packet  Type  8  is  used  for  transmitting  the  ASAT 
vehicle's  appearance.  This  protocol  translator  will  use  a  Packet 
Type  8  to  extract  the  information  necessary  to  create  the  VA  PDU 
template.  The  structure  of  ASAT  Packet  Type  8  is  shown  in  Figure 
7b.  Once  this  packet  is  received  into  the  translator,  the 
information  from  the  highlighted  fields  is  extracted  and 
manipulated  to  correspond  with  the  SIMNET  format,  and  then  placed 
into  a  SIMNET  VA  PDU  template. 


Translator  Performance  Tests 

There  are  several  considerations  when  translating  a  simulator's 
packets  through  a  protocol  translator.  Two  factors  which  are  of 
importance  are  the  amount  of  increase  in  traffic  on  the  network, 
and  the  transmission  delay  due  to  processing  the  ASAT  packets. 

The  increase  in  network  traffic  must  be  considered  a  factor  in 
networks  which  have  a  limited  bandwidth.  The  increase  in  traffic 
is  proportional  to  the  number  of  simulators  which  are  dissimilar 
to  the  standard  network.  In  our  experiment,  we  had  one  ASAT 
simulator  which  was  connecting  into  the  SIMNET  network.  The 
increase  in  traffic  was  given  by  the  simple  formula: 

Increased  traffic  [one-way  translation]  =  Npt(R,) 

Increase  in  traffic  [two-way  translation]  =  Npt(R„  +  R,) 

where  Npt  is  the  number  of  protocol  translators  on  the  network, 
and  Ra  and  R«  are  the  rates  of  transmission  for  the  ASATs  and  the 
SIMNETs,  respectively.  In  our  experiment  we  had  a  single 
protocol  translator  performing  a  one-way  translation.  We  are 
assuming  that  one  translator  will  translate  the  traffic  of  a 
single  ASAT  simulator.  The  increase  in  traffic  is  equal  to 
adding  another  ASAT  module  onto  the  network.  This  means  that  on 
the  average  the  increase  will  be: 

(1  translator )( 113  bytes/pkt ) ( 12  pkts/sec)=10.8  Kbits/sec 

This  increase  in  traffic  is  merely  0.15%  of  the  usable  network 
bandwidth.  However,  it  must  be  kept  in  consideration  that  the 
ASATs  are  selective  fidelity  simulators  and  do  not  have  as  rapid 
an  update  rate  as  most  flight  simulators.  With  a  network  of  high 
fidelity  simulators,  a  protocol  translator  that  does  not 
duplicate  received  packets  may  be  more  appropriate. 
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Figure  7A 

SIMNET :  Vehicle  Appearance  PDU  Template 


Figure  7B 

ASAT  Packet  8  :  Vehicle  Appearance  PDU 


CthArnAt 


Transmission  delays  are  a  critical  factor  in  the  implementation 
of  a  protocol  translator  because  in  a  distributed  simulation 
environment,  the  systems  can  ill  afford  an  extra  delay  produced 
by  a  protocol  translator.  With  this  in  mind,  we  have  conducted 
timing  tests  on  the  translator.  These  tests  have  produced 
statistics  about  the  total  translation  delay  introduced  by  the 
ASAT/SIMNET  translator.  The  translation  of  the  ASAT  packet  from 
the  format  shown  in  figure  7b  to  the  format  shown  in  7a  caused  an 
average  network  delay  of  29  ms.  This  included  time  of  packet 
processing  at  the  board  level. 


NETWORKING  APPROACHES  FOR  RECORDING  SIMULATOR  FLIGHT  DATA 

Our  experiences  with  simulation  device  protocol  translation  has 
led  us  to  discover  several  approaches  for  recording  of  vehicular 
data.  The  concept  is  to  connect  a  device  onto  the  simulation 
network  to  timestamp  and  store  the  appropriate  packets  into  some 
type  of  memory.  Our  first  approach  was  to  utilize  an  HP  497 2A 
LAN  Analyzer  for  obtaining  data.  The  LAN  Analyzer  performed  in 
an  acceptable  fashion,  however,  with  the  current  Analyzer's 
hardware  configuration,  it  is  impossible  to  access  the  collected 
information  with  another  computer.  This  made  processing  of  the 
data  an  overly  tedious  task. 

The  second  approach  was  to  create  a  timestamping  program  on  a  PC 
that  will  allow  the  PC  to  record  and  timestamp  the  packets 
received  during  a  period  of  transmission.  This  allowed  us  to 
access  and  process  the  packets  received.  The  timestamping 
program  was  successful  in  receiving  and  recording  the  packets 
received  through  the  ETHERNET.  The  Timestamping  Program  operates 
by  accessing  a  3Com  ETHERNET  Adaptor  to  perform  its  receiving  and 
timestamping  tasks.  This  approach  allows  the  packets  to  be 
stored  in  a  format  which  is  easily  tailored  to  the  user's  needs. 
Although  this  technique  was  successful,  it  had  faults  which 
prevented  its  use. 

The  primary  problem  with  the  Timestamping  Program  was  an  inter- 
arrival  time  of  greater  than  27.5  ms  that  produced  an  error  which 
was  too  great  for  this  application.  It  was  discovered  while 
verifying  its  accuracy.  To  verify  the  program's  accuracy,  it  was 
run  concurrently  with  the  HP  4972A  LAN  Analyzer.  The  data 
collected  by  the  PC  was  compared  with  the  LAN  Analyzer  data. 

This  comparison  showed  that  when  an  interval  between  timestamps 
of  greater  than  27.5  ms  occurred,  an  error  of  up  to  30  ms  was 
introduced.  This  error  was  a  result  of  a  one  bit  shifting  which 
occurred  in  the  return  value  of  the  hardware  counter  used  in 
conjunction  with  the  MS-DOS  clock  to  obtain  a  high  resolution 
timestamp.  Thus,  the  fidelity  of  the  Timestamp  Program  was 
limited  to  an  inter-arrival  time  of  27.5  ms  (or  lower)  between 
packets. 
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The  third  approach  is  to  use  an  external  time  source.  Timing 
information  would  be  obtained  from  a  time  code  generator  and 
attached  to  the  packet  as  it  is  stored  into  memory.  This 
timestamped  information  can  be  easily  retrieved  for  analysis. 

This  approach  was  our  eventual  solution.  The  time  code  generator 
that  will  be  used  in  this  approach  is  currently  being  procured  by 
1ST. 


CONCLUSION 

Preliminary  indications  and  tests  show  video  tape  as  a  suitable 
means  to  capture  flight  simulator  data.  The  data  set  can  then  be 
used  as  a  means  to  determine  changes  in  flight  test  data  required 
to  yield  a  pilot-  acceptable  simulation.  It  is  hoped  that  a 
consistent  set  of  change  parameters  can  be  discovered  and  used 
across  flight  simulators  to  increase  the  utility  of  the 
simulator,  and  to  decrease  the  amount  of  pilot  tailoring 
necessary  for  simulator  acceptance.  These  latter  topics  are  the 
subject  of  future  studies  at  1ST. 

It  is  also  fully  expected  that  hardware  and  software  voids  that 
could  increase  simulator  performance  and  utility  will  be 
discovered.  Currently  1ST  feels  that  hardware  gaps  exist  in 
visuals,  networking,  and  control  loading  systems.  Software  voids 
exist  in  reusable  software  which  is  executable  in  real  time,  and 
math  modeling  of  many  avionics  systems.  Visual  systems  and 
networking  are  currently  the  only  known  areas  noted  above 
receiving  attention  and  funding  in  the  research  community.  It  is 
expected  that  when  these  and  other  voids  are  identified,  that 
research  and  development  efforts  will  proceed  to  fill  those 
voids . 
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